The present invention relates generally to a communication between a client device and a server device in a client-server environment, and more particularly to protocol verification in a client-server environment.
A client-server environment refers to a computing model which differentiates client devices (e.g., a laptop or desktop executing a web browser such as Microsoft® Internet Explorer®) from a server device (a laptop or desktop executing a server application such as Apache HTTP server), which communicate each other over a computer network (e.g., LAN or wireless LAN). A client device makes a service request to a server device. Upon receiving the request, the server device performs an operation corresponding to the request to the client device. For example, a web browser in a client device accesses information embodied in a faun of a web page from a web server. Emails and database access are also based on the client-server environment.
In the client-server environment, a client device and a server device communicate with each other by using sessions and protocols such as X/open XA and JMS (Java® Message Service). X/open XA is a standard specified by The Open Group for distributed transaction processing (DTP). A goal of X/open XA is to allow multiple resources (e.g., database, application servers, message queue, etc.) to be accessed within a same transaction while preserving ACID (Atomicity, Consistency, Isolation, Durability) properties across applications. JMS is a messaging standard that allows applications based on Java® to create, send, receive and read messages. JMS enables distributed communication that is loosely coupled, reliable and asynchronous.
These current technologies such as X/open XA and JMS are protocols because they require that actions between a client device and a server device are executed in a strictly predefined sequence. For example, a request Open_channel can only be followed by a response ACK (Acknowledgement). Thus, the strictly predefined sequence determines which action can be executed next. However, in a multi-threaded system where such sessions are shared between threads, errors can be introduced that violate such protocols when issuing a command out of sequence or closing a communication session that is being used by another client device. Such errors may first be shown in a different component other than where those errors occurred, e.g., a server device displays an error, which has been caused by a client device. This (i.e., detecting an error later in a different component) can increase error diagnosis time.
Thus, it is desirable to provide a system and method that identifies an error in a protocol immediately at a source of the error (i.e., at a device where the error occurred) and that immediately provides an error notification to the source.